Dynomotion

Group: DynoMotion Message: 13373 From: Colin Fera Date: 6/18/2016
Subject: difference between exec/wait and exec/wait/sync
Hi,  What is the difference between exec/wait and exec/wait/sync?

When would you use one or the other?

Thanks,
Colin
Group: DynoMotion Message: 13374 From: Moray Cuthill Date: 6/18/2016
Subject: Re: difference between exec/wait and exec/wait/sync
From the manual-

Execute a C Program in the KMotion Control Board + wait for it to terminate Execute a C Program in the KMotion Control Board + wait for it to terminate + resync Interpreter positions

Sync essentially flushes the planned motion buffer, and needs to be used if the C Program alters an offset which would subsequently cause the planned trajectory starting point to of changed.
I.e. if your C program does a tool change where the new tool length offset is different, if you don't re-sync, the initial move will cause a jerk as it jumps to the previously planned trajectory position. Sync will flush the buffer, and recalculate the planned motion from the new offset.

Moray

On Sun, Jun 19, 2016 at 2:04 AM, Colin Fera colin.fera@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi,  What is the difference between exec/wait and exec/wait/sync?

When would you use one or the other?

Thanks,
Colin
Group: DynoMotion Message: 13375 From: Colin Fera Date: 6/18/2016
Subject: Re: difference between exec/wait and exec/wait/sync
Thanks, that was what I needed.

Colin

On Sat, Jun 18, 2016 at 6:16 PM, Moray Cuthill moray.cuthill@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

From the manual-

Execute a C Program in the KMotion Control Board + wait for it to terminate Execute a C Program in the KMotion Control Board + wait for it to terminate + resync Interpreter positions

Sync essentially flushes the planned motion buffer, and needs to be used if the C Program alters an offset which would subsequently cause the planned trajectory starting point to of changed.
I.e. if your C program does a tool change where the new tool length offset is different, if you don't re-sync, the initial move will cause a jerk as it jumps to the previously planned trajectory position. Sync will flush the buffer, and recalculate the planned motion from the new offset.

Moray

On Sun, Jun 19, 2016 at 2:04 AM, Colin Fera colin.fera@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi,  What is the difference between exec/wait and exec/wait/sync?

When would you use one or the other?

Thanks,
Colin
Group: DynoMotion Message: 14629 From: kovkaa Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync
HI.
I apologize for my "stupid" question, but after several hours of searching on the net I was't able find the manul you refer to. Plaese help me in this situation.
Best regards,
Alexander Kovylkin.
 
Group: DynoMotion Message: 14630 From: Colin Fera Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync

On Apr 23, 2017, at 5:00 AM, kovkaa@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

HI.

I apologize for my "stupid" question, but after several hours of searching on the net I was't able find the manul you refer to. Plaese help me in this situation.
Best regards,
Alexander Kovylkin.
 
Group: DynoMotion Message: 14631 From: kovkaa Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync
Hi.
Many thanks for reply.
But in this case I have a question that in my opinion is important for security. When execute/wait or execute/wsit/sync  all objects on the form are blocked until the program finished. Together with all the BIG RED BUTTON also blocked. This is not very good. If i using execute prog options all buttons still is active and carelessness (accidentally pressing any form button) can lead to problems when performing a home position operation and the like.
Bets regards,
Alexander Kovylkin.
Group: DynoMotion Message: 14632 From: Colin Fera Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync
I have an external estop button on a kflop gpio. This isn't effected  by exec wait.

Using a mouse or keyboard shortcut to try and hit an estop software button in a windows program on a CNC machine other than maybe a desktop 3D printer is sketchy in my opinion. 

Windows could crash or bluscreen.

Sent from my iPhone

On Apr 23, 2017, at 6:43 AM, kovkaa@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi.

Many thanks for reply.
But in this case I have a question that in my opinion is important for security. When execute/wait or execute/wsit/sync  all objects on the form are blocked until the program finished. Together with all the BIG RED BUTTON also blocked. This is not very good. If i using execute prog options all buttons still is active and carelessness (accidentally pressing any form button) can lead to problems when performing a home position operation and the like.
Bets regards,
Alexander Kovylkin.
Group: DynoMotion Message: 14633 From: kovkaa Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync
Hi.
All this correct, but for an example: during the execution of the G code, an emergency stop button in the windows program still is active. This is more logical than blocking any object in the KmotionCNC. I would like to hear Tom's opinion opinion on this issue..
Best regards,
Alexander kovylkin.
Group: DynoMotion Message: 14634 From: Moray Cuthill Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync
I'll add a couple things to this discussion.
You don't normally need to wait for homing. Wait is for something that needs to occur during the normal running of G-code, where you want G-code execution to wait until the user program is complete.
A good example is a tool change, where you need G-code execution to be paused until the tool change is complete. It's also worth mentioning that for a toolchange, you would also normally use the sync option, as once the toolchange is complete, the tool offsets will usually of changed, so motion has to be regenerated/synchronised using the new tool offsets/position. If you don't use sync, there will be a sudden non trajectory planned motion command once the g-code is resumed.

The stop button within KMotionCNC is just that, a stop button. It is not an E-stop button. E-stop should be handled in such a way software is not relied on to halt motion. I always implement E-stop in hardware i.e. hitting the E-stop kills power, with the KFlop being notified an E-stop has happened.

I'm not sure how you are getting KMotionCNC blocking during program execution, as the only time I'm aware that there should be blocking is when a user input has been requested. On my machines I can still use the Stop (or Esc key) within KMotionCNC during user program execution. Perhaps  if you posted up what code you are using, somebody will be able to advise you of how better to handle things.

Moray

On Sun, Apr 23, 2017 at 3:15 PM, kovkaa@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi.
All this correct, but for an example: during the execution of the G code, an emergency stop button in the windows program still is active. This is more logical than blocking any object in the KmotionCNC. I would like to hear Tom's opinion opinion on this issue..
Best regards,
Alexander kovylkin.



Virus-free. www.avast.com
Group: DynoMotion Message: 14635 From: kovkaa Date: 4/23/2017
Subject: Re: difference between exec/wait and exec/wait/sync
Hi
     In the continuation of the discussion. I slightly disagree with the fact that the STOP button is not an emergency button. After clicking on it, it turns off all axes and stops all threads of the program(excluding thread one). After this operation, you need a complete reinitialization of the system (home position, etc.).
     I think, it's not a logical that executing the same program with the same options(execute/wait/sync) blocks the form in different ways. If the program is started using a user button, the form is completely blocked. If the program is started through the MDI, the stop pause and halt buttons remain active. In order to verify this, it is enough to run the simplest program 
main()
{ for (;;)
}
Also, if the program is launched through a user button, KMotionCNC stops responding to any command from the internal program like DoPC() and etc. This, I think, is also not very good.
At the same time, I absolutely agree with you that the emergency button should lock the driver hardware, disconnect the power supply, and so on.
Best reagards,
Alexander Kovylkin.
Group: DynoMotion Message: 14636 From: Tom Kerekes Date: 4/24/2017
Subject: Re: difference between exec/wait and exec/wait/sync

Hi Alexander,

You bring up a good point.  We've discussed this in the past.  Currently the Screen Buttons use the GUI Thread to perform the Action.  So if the Action is set to wait the entire GUI is blocked until the operation completes.  It probably doesn't make sense to use a wait with a Push Button.

GCode Executes from a separate PC Thread so as it is waiting the GUI is not blocked.  We've considered using a worker Thread to perform Button Actions.  But that might cause other problems. 

There is a command to disable the Jog Buttons from KFLOP that you might call from your Homing Program and others if that helps.

Regards

TK


On 4/23/2017 11:22 PM, kovkaa@... [DynoMotion] wrote:
 

Hi

     In the continuation of the discussion. I slightly disagree with the fact that the STOP button is not an emergency button. After clicking on it, it turns off all axes and stops all threads of the program(excluding thread one). After this operation, you need a complete reinitialization of the system (home position, etc.).
     I think, it's not a logical that executing the same program with the same options(execute/wait/sync) blocks the form in different ways. If the program is started using a user button, the form is completely blocked. If the program is started through the MDI, the stop pause and halt buttons remain active. In order to verify this, it is enough to run the simplest program 
main()
{ for (;;)
}
Also, if the program is launched through a user button, KMotionCNC stops responding to any command from the internal program like DoPC() and etc. This, I think, is also not very good.
At the same time, I absolutely agree with you that the emergency button should lock the driver hardware, disconnect the power supply, and so on.
Best reagards,
Alexander Kovylkin.